@felixmosh I added some scripts to the build process #26 let me know what you think and if you see any issues with this method to minify tailwind.css.liquid

@felixmosh I added some scripts to the build process #26 let me know what you think and if you see any issues with this method to minify tailwind.css.liquid

It looks ok 👌

Update: I’ve tried to use liquid-section-tags, looks like it is unfinished, therefore not working.
I’ve opened an issue trying to help.

I've made a PR in harttle/liquidjs-section-tags#13

In the meantime I copied the code to the repo, looks like section & schema works 🎊

As you can see the menu disappears because linklists is not available locally.

Very cool, I HMR with Schema is really nice.

@3daddict I've dug around Shopify api and seems that there is no one for fetching sites "meta-data" (such as menus).
I your opinion, is it ok to require users to provide is statically (as json)?

@felixmosh yeah unfortunately there is no way to import or export menu items in Shopify. I have been wanting them to add this for some time now. Static JSON would be a good solution to get around this until we can pull from the admin which may never happen.

An update, tag / filter wise it is pretty simple to mimic shopify's tags / filters.

There is a blocker that I've encountered, since we are compiling liquid templates offline (without context of the current page). I'm not sure if this is "OK".
One option is to provide some data, for example, if you are working on some collection page, so provide one of the collection data.
Other option is to move liquid file compilation to the browser, this will introduce other issue, since some liquid tags/ filters which loads other files won't work.

WDYT?

@felixmosh I should have mentioned this earlier and you might already know of this but Slate runs a dev server with Liquid: https://shopify.github.io/slate/docs/local-development
Repo: https://github.com/Shopify/slate

Slate is like ThemeKit made by Shopify but they have abandoned the project. I wonder if looking into how they have solved this might give you some ideas?

I've looked into it,
They wrote in the docs that it doesn't supports the " new section theme architecture" and probably they didn't had HMR for liquid files :]

It is a matter of decision :)

Haha this is a tough call. One more for you to see if you haven't already: https://github.com/hayes0724/shopify-webpack-themekit here they have made some Middleware for Shopify preview?

If that is not of much help then how would we provide some data, for example, if you are working on some collection page, so provide one of the collection data?

I'm already fetching the store data using gql storefront api.

The issue is that I'm not aware of the page that you are in, so, the worst case scenario if you on product z, I will switch it to product a

https://github.com/hayes0724/shopify-webpack-themekit doesn't supports HMR at all

Thanks @felixmosh
For development purposes defaulting to a page a would not be that bad. It should be sufficient to build out page features since they are templated anyway. Exited to try it out. Let me know if I can help with anything.

I'm trying to keep the list of filters/tags as updated as possible.

We need to finish them.
Filters are easy things to implement, i just don't have enough time lately to work on it.

Any help is welcomed.

@felixmosh happy to help here where I can.
Do you need me to update the different types of Filters & Tag that we have for all possibilities?
or
If you need me to work on some of the code & logic let me know where I can step in and help.

Hi @felixmosh,
@davidwarrington presented an interesting idea using BrowserSync I wanted to run by you.
https://github.com/davidwarrington/shopify-webpack/pull/6/files. He's using BrowserSync to handle the assets through middleware and watch for file changes. I wonder if we can do something similar with webpack dev server to avoid that liquid blocker discussed earlier and filter maintenance?

HMR for this project in its simplest form is to watch for file changes and then re-run run build & themekit commands to upload the compiled changed files and then force the browser reload. If we can compile files on change and then watch them in themekit, then themekit will upload the files and forcing a browser refresh will load the updated files. This would eliminate the need to host the files on the dev server path which might simplify things?

I know things are busy and I am also trying to find time to build out a full test store to see if we run into any issues as a theme gets bigger and more complex. Both the current method in progress and idea above are over my head so my question is more to learn than suggest. Let me know what you think and I'll work to build out a test theme in the meantime as we finalize this solution.
Thanks!

Hi, Just wanted to update regarding the fact that I don't have much time lately.

Basically it works, and it works pretty well, the "issue" is that there are some tags / filters that are shopify only.

I don't like the idea to upload each time to Shopify, it is slow.

Any way, it was COOL experience to implement what we achieved. :]

I will remain this PR open since there only few tags ....

Thanks @felixmosh it's really cool what you have made here. I'll work to get this merged and we'll start the first release of this project. Thanks for your help on this, I have learned a lot from your contribution and what you have implemented was HUGE!

I agree to upload each time to Shopify is slow if it's loading all the files each time and not just the files changed. There are advantages to running the dev server like you have made it for sure and I am excited to see where this concept will go.

Liquid HMR seems like a fantastic idea @felixmosh. I fully agree that reuploading liquid files on change is not ideal. The main reason I've personally not reached for something like Liquid HMR is because I know I probably won't have time to maintain it, and I'm not in a position where I can afford to wait to update a Liquid loader if a large batch of new features are released. I'm mainly thinking of the upcoming Sections Everywhere update here.

Also, apologies if I've just missed it in your code, but how do you plan to make the API endpoints available to users? In a lot of the stores I work on we regularly use endpoints like /cart.json, /collections/:collection.json and /collections/:collection/products.json. Is your dev server proxying those at the moment?

I think if you're able to pull this feature off a lot of people in the community would be keen to switch to this toolset, and that may in turn make Liquid HMR easier to maintain going forward if the community begin contributing.

@davidwarrington than you for the warm feedback 🙏🏼

Basically, the idea is simple, pre-compile liquid files in node, and send the results to the browsers, this idea fully works already in this PR. It event access to the shopify front api in here, the only downside of this, is that it is "out of context" from the page that you are in... but I guess that this is OK since it purpose is to design the site, not the content.

The only part that is remained "open" are some Shopify specific tags / filters.
Some of them I've implemented...

What you see is that dev server fetches some collection from my store (once at build start) and feeds the data to the "compilation" phase.

It works :]